readme.txt, archive for beta of vers 1.75 of TexNet, compiledate 7/20/98.
This archive presents a betatest (and likely will be a final release)
of V 1.75 of TexNet. It contains config.txt, which documents the
contents of one of the .cmd configuration files. There are several
late configuration .cmd files present, including ones for Lafayette
and Baton Rouge, of interest to WU3V, one of the addresses of this archive.
Included also are HASHEDIT.BAS, needed to generate patches to the
master firecode image FIRE02.BIN (2732). If you are generating a
firecode eprom, start with what you know is a CLEAN copy of FIRE02.BIN.
Using your assigned ascii nodename, up to 7 ascii uppercase alpha(numeric)s,
run HASHEDIT under some basic intrepreter, GWBASIC or similar, and type
in the nodename when requested. It will PRINT a patchlist, in absolute
addresses, you can MANUALLY patch a COPY of FIRE02.BIN. DON'T EVER PATCH
YOUR MASTER COPY OF FIRE02.BIN, YOU CAN'T EASILY UNDO THE CHANGES. NOTE
that the hashing algorithm uses variable patch ADDRESSES, not variable
data at static addresses, and also you may not be able to distinguish
changes with a file checksum, since it is only moving content around.
(Should you inadvertantly mix the contents of two or more patchlists
of different nodenames, the resulting eprom will respond to all character
permutations of both names, and will be much more vulnerable to falsing).
HASHEDIT will also generate a command file that you can redirect to
MSDOS DEBUG which will avoid handpatching from the output list, note
that Debug requires addresses offset by 0x0100, and the file generated
by HASHEDIT takes that into account. Anyhow, make sure you only patch
a COPY of FIRE02.BIN under some other name, and then burn that into
a 2732, and plug into the firecode socket of the NCP board. There is
a 3 pole jumper header nearby that socket, one position ignores the
firecode socket and is used if the socket is empty. The other position
responds to the firecode socket, but if there is not a programmed eprom
in the socket, it will hold the Z80 in a constant reset condition and
the node won't come on line. There is a RC timer associated with that
circuit, set for 1-3 minutes, and it will hold the Z80 in reset for that
length of time following a powerup or a remote reset. That long time
constant is intended to time-out any remote trunk connects to the node,
so that all connections will start fresh every time, not carrying any
previous content into a recently reset node that is coming on line.
There are also files CRLS01.BIN and CRHS01.BIN, which can be used to
create the 2716 eproms used in the bitsync/state machines of the
1200b and 9600b TPRS modems respectively. These state machines are
pinned differently than the ones in TAPR TNC's, so are non interchangeable
with TAPR state machine eproms, also they have code to generate a TX
clock to take the place of external divide by 16 hardware. The 9600b
eprom has been "tweaked" to optimize bit error rate for that modem, so
isn't exactly the same as the "standard" recovery scheme used for AFSK.
Note that here also, eprom checksum may not disclose different files, since
things have been relocated, so do a file compare with known original images
if you are uncertain of the contents of any particular file.
There is no node-specific information contained in these two modem eproms,
so they should only need to be reburned if the eprom goes bad or
wasn't included to begin with. The firecode eprom only needs to be burned
once, with the ascii nodename, it doesn't change if other software changes,
unless the nodename also happens to change, and normally will only need
to be replaced if the eprom goes bad. Of course, the main 27256 eprom
will change every time the code or the parameters are changed for any reason.
In this release, the address for the RAM parameters starts at 0x6406.
For those unfamiliar with it, it is a RAM image of mostly L2 parameters
that were set individually for that node in the eprom by the configuration
process, and they can be remotely patched on the fly for temporary
tweaking. They aren't preserved during resets, so they must be
made permanent by reburning the eprom.
There are considerable changes to the code to add APRS compatibilty,
so there are major additions to the configuration. Added are some digi
addresses to support more recent techniques that APRS is using to make
digipeats more flexible. Added is an ID string that is transmitted
along with the regular ID string used previously, that APRS will use
to locate the node on a map. Also added is an entry to direct APRS content
received over the network to one port of the node. The code itself adds
lots of logic to handle APRS frames over the network.
The actual dynamic routing table in the node itself has been partitioned
into two sections: slots 1-80 are the old routing table used exactly as
before (which used to be 90 slots), and slots 81-90 which govern destination
node numbers for various APRS destination callsigns, and wildcards are used,
and really are necessary in fact. The whole table is still displayable
and editable with previous known methods, and the APRS destination entries
are sysop manual entries only. A typical entry might look like:
81 = 024 025 048 080 000 APR????
This line means to scan for any "to" callsign in a UI, which is otherwise
eligible for the node to digipeat anyway, and if it has the three
characters "APR" followed by any other 3 characters whatsoever, and any
SSID 0-15, then it needs to be sent to nodes: 24 (AUSDXC), 25 (ARESTC),
48 WACO), and 80 (AOHPMS), and there is one spare slot. Up to 5
destinations can be specified, zero is inactive. The network sysop
would use the following edit sentence to load the string into node LFTDXC:
R C 81 = APR????, 24 25 48 80 0 @LFTDXC
The sysop may choose to put these edits into an upload file. Note that
there is no automated means for entering them, the sysop must do so, and
needs to check from time to time to see that they remain intact, they
need to be reloaded if the node is restarted.
The archive also contains a clean copy of the main binary NCP_175.BIN,
which is edited by the script that is fed to Debug, or the regular
configuration tool, when the master template for that is prepared, when
the final release is issued. Create copies of that file under different
names for different nodes. Retain the files in case an eprom goes bad
and needs to be replaced. Since the debugger can't tolerate comment lines,
a separate file CONFIG.TXT has been created to help talk the user through
the contents of the .cmd files, it happens to be that of the Lafayette node.
This first attempt at a config for Lafayette and Baton Rouge is done knowing
only basic info about the node. Some of the contents are assumed, and the
lat/long in the APRS ID string just reflects some place in the center
of what looked like downtown on the APRS maps for those parishes, the
PHGD data is not known either, and may need to be tweaked.
This code doesn't yet have logic for KISS ports, which is essential for
internet trunking. That will be on the next release, but this release will
allow for initial RF testing. Expect in the next config file for that coming
release to have some means of specifying, on a port by port basis, whether
the port will run HDLC or async KISS at layer 1. It will PROBABLY be
a 4 port system, and I haven't yet decided how to treat the local console
port. It is looking like there will be some need for more than one kiss
port per node, so it will be made a parameter for each port, and likely
port 0 and 1 will be HDLC as we know them now, port 3 (the console socket)
will be KISS, and port 2 could be either. The configuration should allow
for any combination of either kind on any port, but note that as presently
WIRED AND STRAPPED, ports 0,1,2 are HDLC, and port 3 is async, so if a
departure is made from that scheme, hardware modifications will be necessary.
Those mods are limited to interfacing leads from the SIO to port pins and
clocks in particular, and have been done before for things like weather
wire inputs on port 2 and the like, and are straightforward stuff.
This release will more than likely freeze here with the code compiled
on July 20 1998, unless something bad turns up in the next few days.
It isn't perfect, but it doesn't have any bad gotchas that have come
to light yet either, and appears to be as reliable as previous stuff.
The next release will continue with the "to-do" list and include KISS
for internet trunking along with whatever else appears to be needed
or wanted that will fit.
At some point, codespace will have to be expanded by changing to 27512
eproms, and bankswitching one eprom address lead. This is a simple hardware
mod, consisting of cutting a board trace that pulls up eprom line A15 to +5V.
That pin will re-route to an SIO output, in much the same way as was done
for the TNC2 27512 mods, and of course require new software and bigger
eproms to match, and of course we have to keep track of which nodes have
been modified and which ones haven't. That is still under development
as far as software is concerned.
Live Music
Archive
Librivox
Free Audio
Metropolitan Museum
Cleveland
Museum of Art
Internet
Arcade
Console Living Room
Open Library
American
Libraries
TV News
Understanding
9/11
Digital Library of Amateur Radio & Communications
DLARC Software
